关于软件架构师这个角色的一些看法 A few thoughts on the role of software architects

作者：Joe Duffy，时间：2008-10-02

The word “architect” means different things to different people in the context of software engineering. And it varies wildly depending on the kind of organization you’re in. An architect at a medium sized IT shop might focus on connecting disparate business systems together at a high level, but without diving down into code. An architect at a startup may be more like a tech lead, checking in code like mad, but also keeping the rest of the team in check. And a software architect at Microsoft can play an even varied number of roles because the company is so large and diversity of projects so great.

“架构师”（architect）这个词，即便是在软件工程这个语境里面，对不同的人来说也意味着不同的事物。并且这个概念也随着你所在的组织不同而变化。一个中型IT服务机构的架构师更专注从高层次上把相互隔离的业务系统关联到一起，而不是深入抠代码细节。一个创业公司的架构师则更像是一个技术经理（tech lead），像疯了一样频繁提交代码，并且也驱使团队其他人保持同步的节奏。而微软的软件架构师，由于公司足够大项目足够丰富，则可以充当更加多变的角色。

A colleague and mentor of mine who I respect greatly says that an architect is the guy (or gal) who is in charge of making those decisions which, if made incorrectly, could sink the project.

一个同事（同时也是我非常尊重的导师）说，架构师就是负责做影响项目命运的决定的人。

There is a lot to be said for this. These decisions are those with the broadest, deepest, and longest lasting impact. The decisions themselves are often made by team members initially, but the architect is responsible for providing constant and rigorous technical oversight. Architects set the high level technical agenda, look ahead several releases, and keep the team on course. They are ultimately to blame if the technical foundation is unsound and/or final solution fails to meet expectations. Their butt is on the line.

这方面其实可以探讨很多。这些决定都是影响范围广、程度深而且持续时间长的。通常都是由团队成员首先提出提议，但架构师应当负责提供持续并且严格的技术监督。架构师要有一个高层次的安排，提前规划发布，并且保证团队按照规划前行。如果技术基础不够健全或者最终的解决方案不符合期望，他们是最终受责备的人。他们行事如履薄冰。

On one hand, an architect is the lead engineer with most at stake in the project. On the other hand, an architect is more like a member on the project’s board of directors, providing high level guidance and meddling as little as possible (but as much as is necessary) in the day-to-day details.

一方面，架构师是项目中至关重要的领队工程师。另一方面，架构师更像是项目委员会的一员，在提供高层次的指导和对日常细节的尽可能少（但必要）的干预。

An architect’s success is measured by what he or she ships to customers, and not by the amazing ideas that were ultimately never realized. This necessarily means an architect’s success is deeply rooted in the team’s culture, work ethic, and ability. He or she needs to work through others to get things done.

架构师是否称职给客户提供了哪些价值来衡量，而不是他们提出了什么神奇（并且有可能实现不了）的想法。也就是说一个架构师的成功，跟团队的文化、工作激情和能力都有着密切的关系。他们要达到目标的话也必须完成这一切事情。

There have been some great architects throughout the course of computer science, but who may not have been labeled as such. Linus Torvalds is the architect of Linux, and David Cutler the architect of Windows NT. John Backus was arguably the architect of FORTRAN, Niklaus Wirth the architect of Pascal, Bjarne Stroustrup the architect of C++, James Gosling the architect of Java, and Anders Hejlsberg the architect of C#. Bill Gates was the architect of Microsoft BASIC, and Charles Simonyi the architect of the initial versions of Microsoft Office (Word and Excel). In each case, you can see that the end result is very reflective of one person’s value system and ideas, but took a lot more than just that person to be successful. Each of these people learned to let go of their project just enough that it could achieve the scale that it was meant to achieve, but not so much that the project veered off course. Some projects have multiple architects, but the successful ones usually have one who is really in charge.

也有许多伟大的架构师遍布整个计算机科学的发展进程，但并没有被标记为架构师的角色。Linus Torvalds是Linux的架构师；David Cutler是Windows NT的架构师。John Backus可以认为是FORTRAN的架构师；Niklaus Wirth，Pascal的架构师；Bjarne Stroustrup，C++的架构师；James Gosling，Java的架构师；Anders Hejlsberg，C#的架构师。Bill Gates是Microsoft BASIC的架构师；Charles Simonyi，Microsoft Office早期版本（包含Word和Excel）的架构师。每个例子里面，你都能看到这些最终成果都能直观地反映这个人的价值观和思路，但都需要更多的人的力量，才做到如此的成功。这些人都明白，把项目一定程度地放手能够达成这个项目原本预计的目标，但也不能过度放松致使迷失方向。一些项目可能有多个架构师，但成功的这些通常只有一个真正主导的人。

Already you can see some subjective opinion being thrown into the mix, and some of it is apt to be controversial. Although not comprehensive, I’ve put together seven guiding principles that I personally aspire to. I’ve certainly not mastered them all, but have always looked up those people around me who seem to have. Why seven? No reason, really. Over the past few years, I’ve tried to spend as much time as possible learning from successful architects, and these stand out in my mind as being the key common attributes that appear to be common among them.

你已经发现我抛出了一些偏主管的观点了，其中一部分是有争议的。尽管并不详尽，我这里选了我个人追求的七条指导原则。当然这些原则并不是我完全掌握了的，但包含我一直在观察的周围的人所采用的。为什么是七条？没有原因，真的。过去的几年里，我尝试花尽可能多的时间来学习一些成功的架构师，以及我印象中突出的他们关键的一些公共特征。

0. Inspire and empower people to do their best work.

0. 启发和授权人们做到最出色的工作

Architects ultimately succeed or fail based on the quality of people on their team. Knowing how to inspire and empower these people, so that they can do their best work, is therefore one of the most important skills an architect needs in order to be successful.

架构师们的成败与他们团队成员的工作质量密切相关。因此知道如何启发和授权这些人去完成他们最出色的工作，是架构师为了成功而需要的最重要的能力之一。

You can’t do it all yourself. This can be frustrating at times, and at times you might think that you can (particularly in times of frustration). I’ve personally hacked together 1,000s of lines of code that I’m incredibly proud of in a weekend, and that would have taken weeks or months to get done if I had to instead explain the idea to somebody else and wait for them to write those same 1,000s of lines of code. And the 1,000s of lines they write of course wouldn’t end up being the same as the ones you’d have written. And they may decide that they don’t like the design after all, start discussing it with colleagues, stage a mutiny, and ultimately overthrow what once seemed like a great idea. This is a tough pill to swallow. But it’s a sad fact of life that you need to learn to be comfortable with.

你不可能做所有的事情。这可能经常让人感觉很丧，也经常你或许认为自己可以搞定一切（特别是比较丧的时候）。我曾经一个人在一个周末糊了1000多行的我感觉让我非常自豪的代码，如果交给我指导的其他人去完成这同样的1000多行代码，可能会花费好几周甚至几个月。并且他们写的这1000多行代码当然不一定跟我写的一样。他们也许根本不接受这个设计，开始跟同事讨论，站在对立的立场上，甚至是推翻这个看起来还算不错的思路。这种感觉如鲠在喉。但这是个很不幸的事实，你需要学会去适应。

The same thing would have happened if you were the one to implement the idea, of course; the difference is that somebody else needs to be empowered to take the kernel of an idea, and run with it. That entails reshaping it as necessary to make it realistic and successful.

如果是你来实现这套思路也许会发生同样的额事情；不同的是，需要授权另外的人来提取这个思路的核心，并且执行下去。被赋权者需要进行必要的重构来让这件事情可行并取得成功。

I’m not suggesting architects don’t write code (quite the opposite: see #3 below), but you can’t write it all (except for very small projects). If you buy the argument that an architect is just the leading senior engineer on the project, then by definition the architect is probably qualified to write quality code quickly. But what about the code they don’t write? Other people on the team need to write it, and the architect needs to have enough time (where he or she isn’t hacking code) to inspire those people to write the right code. This takes energy and effort. You need to paint a compelling picture of the future, but with enough open-endedness such that the team can flex their creative muscles and fill in the details.

我并不是建议说架构师不要写代码（恰恰相反，参考下面第3条），但不能全部的都由你来写（除非是非常小的项目）。如果你认为架构师只是领导型的高级工程师，那么按理来说架构师大概是有能力很快写出高质量代码的。但是那些不是由他们写出来的代码怎么办呢？这些代码需要由团队里的其他人来完成，而架构师需要有足够的（不在糊代码的）时间指导这些人如何正确的编码。这需要一定努力。你需要画一幅酷炫的图画，并且还有足够的开放空间来给团队成员施展，填充细节。

This is the only way to scale. And architects need to scale to achieve broad impact.

这是唯一的能够扩展团队能力的办法。一个架构师需要这样的方式来扩展，进而提升更广泛的影响力。

Architects should also welcome all ideas with open arms. You want to foster an open and energetic environment on your team, where intellectual debate is the norm. All ideas are fair game.

架构师们应该以开放的心态接受所有的想法。想要养成一个开放并且有活力的团队氛围，知识性的辩论是常态。所有的想法都应该被公平对待。

That’s not to say all ideas are good ones, and ultimately the bad ones need to die a quick and painless death before going too far, but an architect who won’t even entertain new ideas from the team (typically because of NIH syndrome (i.e., Not Invented Here)) often drive away the best engineers. Great engineers hate to be told what to do. They don’t want to feel like they are walking in the shadows of somebody else. They want to use the skills that make them so great, which involves inventing bigger, badder, and more impactful designs. And you want them to use these skills too, because that’s why you hired them: these skills are crucial to the success of your project. Part of your role as the team’s architect is to recognize who on the team has the most potential, and to arrange for them to have as much leeway and creative freedom as possible. You don’t want to end up with a bunch of lackeys whose job is to “just implement” your ideas, because you’ll get what you paid for.

这并不是说所有的想法都是好的，并且最终这些不好的想法需要在造成深远影响之前尽快给安乐死掉；但那些不待见团队新想法（通常产生于NIH综合症）的架构师，通常很难留住团队最好的工程师。好的工程师讨厌被指导做事情。他们不希望自己行走在别人的阴影之下。他们希望通过创造更大、更好、更有影响力的设计，展现他们的能力和价值。你肯定也希望他们能用这些能力好好发挥，毕竟这才是你为什么要雇佣他们的原因：这些能力对你项目的成败，是至关重要的。你作为团队架构师这个角色的一部分职责是辨别出团队中最有潜质的人，并且给他们安排尽可能多的自由创造和发挥的空间。你肯定不想到最后跟一群只奉承你的主意行事的舔狗们做事情，因为这样的话你不会有好果子吃的。

It’s a true sign of success when the culture you impart unto your team allows them to invent things in the spirit of your own design principles, but without you needing to do it yourself. Jim Gray, for example, inspired countless people to do great things. Does he get credit for each of those ideas? Of course not. But was he indirectly responsible for them to some degree, and do they all have a little Jim Gray in them? Absolutely. Being an architect on a team is similar; not every idea has to be your own. In fact, it’s far more powerful if few of them are.

当你的团队文化允许成员在你的设计原则指导下创造自己的东西而不是由你来亲为的时候，这就意味着成功了。比如，Jim Gray，影响了无数的人完成伟大的事业。他有因为这些人的想法而出名吗？当然没有。但是他是否一定程度上间接影响了他们，并且他们做的事情也都有一些Jim Gray的痕迹呢？绝对是的。作为一个团队的架构师，这方面是类似的；并非所有的想法都必须是由你提出的。事实上，由你来主导的想法越少，反而效果越好。

1. Oversight, but not dictatorship.

1. 监督，而非独裁

That brings me to technical oversight. Because an architect is typically not a manager for his or her project (although in some cases he or she may be), arms-length influence needs to be used to get things done. In fact, the architect may have very little to say over specific project management, scheduling, and budget decisions, but is typically on the senior leadership team for the project. So when I talk about “leeway” above, I’m talking about the degree to which an architect monitors and attempts to meddle with the progress of the team. While it’s tempting for an architect to set the ship sailing to sea, and then turn around to work on the next big thing, this almost never works. The initial vision and idea is far from a shipping solution, and software engineering only gets interesting once you actually try to build something. Ideas are cheap. The architect needs to help the team work through the ramifications of certain technical decisions that were made up front, and help with the continual course correction.

这让我想到了技术监督这件事儿。因为架构师通常来说并非是他们所在项目的经理（当然有些情况下可能是），arms-length influence needs to be used to get things done. 事实上，架构师可能在项目管理、进度和预算方面有很少的话语权，却通常是项目团队的高级领导者。所以我前面提到的“自由空间”，指的是一个架构师监控和尝试干涉团队进程的度。尽管看起来说扬帆起航以后转身投入下一个伟大的项目是很吸引人的，但通常来说这几乎不可能。最初的想法和视野距离最终方案还有很长一段距离，一旦你正式尝试构建什么的时候就有必要用上软件工程了。提出想法很容易。架构师们需要带领团队实现一系列预先做好的技术决策，并且帮助持续地调整团队前进方向。

Because an architect’s butt is ultimately on the line, he or she needs to work as fast as possible to correct problems when something goes wrong. This implies the architect is involved enough to notice when something goes wrong, hopefully well in advance of anybody else seeing it. I’ve seen many models that work, ranging from the architect being the approver for all major design decisions, to the architect simply reviewing all major design decisions after-the-fact, to the architect delegating this responsibility to trusted advisers. For example, Linus Torvalds for the longest time required that all checkins to the Linux code base be reviewed by him. Anders Hejlsberg still effectively approves each C# language design change. In my opinion, the closer to each major decision the architect can afford to be, the better.

因为架构师通常如履薄冰，他们就要在任何事情出错的时候尽可能快地解决问题。这就意味着，当有意外发生的时候，架构师应该保持足够的关注，最好是在所有人可能遇到这个意外之前发现它。我见过很多可行的范例，从作为所有主要设计决策的批准者，到简单地事后审查所有主要的设计决策，到把这部分责任委托给可信的顾问等。例如，Linus Torvalds在很长一段时间里都要求所有到Linux代码库的提交交给他审查。Anders Hejlsberg依然实际批准每一个C#语言设计改动。我认为，对每一个主要的决策，架构师参与程度越深，效果越好。

Left to its own devices, the team would veer off course in no time. That’s not because of malicious intent, but rather because of the sheer diversity of software engineers. This diversity is present on many levels: in skill level, taste (which is hard to measure: more on that in #2 below), motivation, work ethic, interpretation of the vision, personal beliefs and experience, and so on. An architect acts as a low-pass signal filter, smoothing out any irregularities that deviate too far from the core design principles.

In Tony Hoare’s ACM Turing Award paper of 1981, The Emperor’s Old Clothes, he explains the risk of not providing this kind of architectural oversight:

“‘You know what went wrong?’ he shouted - he always shouted – ‘You let your programmers do things which you yourself do not understand.’ I stared in astonishment. He was obviously out of touch with present day realities. How could one person ever understand the whole of a modern software product like the Elliott 503 Mark II software system? I realized later that he was absolutely right; he had diagnosed the true cause of the problem and he had planted the seed of its later solution.”

Sadly, this responsibility often entails being “the bad guy”. Sometimes you need to mercilessly kill an idea because it would put certain parts of the project at risk. Other times you need to let somewhat bad (but not too impactful) ideas go. There’s a tradeoff here, because each time you kill an idea you’re going to leave somebody feeling burned. And you may waste peoples’ time, depending on how much time has already been invested in that idea. Some battles are best left unfought. There is an art to be learned here: if you can get those with the idea to firmly believe that there has to be a better way, you can avoid being seen as the bad guy. “Sit back and wait” can work in some cases, but it can backfire too.

The deep involvement in the technical design details unfortunately means that the architect can become the bottleneck if he or she is not careful. This can slow the team down. Some slowdown can admittedly be a good thing, because it has the effect of forcing more thoughtfulness in each and every decision. But as the team grows, the granularity of decision oversight necessarily has to change to ensure the team is empowered to make progress. In order for this to work, you need to have trusted individuals who are involved at a finer granularity and will use the same principles and values. This takes trust and time.

2. Taste is a hard thing to measure, but is invaluable.

Software engineers like to measure. Many people try to make design decisions based on quantitative data, even though they know that engineering is more of an art than a science. But there is one common trait that, as far as I can tell, is impossible to measure, and yet common to all of the great software architects I know: good taste. And because it’s impossible to measure, those who lack it have a hard time understanding the difference between a design with good taste and one with bad taste.

There is a certain elegance and beauty to the designs created by architects with good taste. When you see it from a distance, you know it, but when viewed under a microscope—the kind of microscope used when debating the finer points with other engineers on the team—it is much harder to detect. Often it’s incredibly difficult to articulate why some particular design has good taste, which makes it even harder to justify. Eventually people are willing to trust your judgment because they begin to see it too.

In fact, good taste is perhaps one of the most important skills an architect needs to have. Bad taste leads to clunky designs that nobody likes to use. Steve Jobs knows this. And yet taste is probably the most difficult skill for an architect to develop, and one of the subtler ones that few people recognize as being necessary. Many managers think that throwing more engineers at a design problem will solve it, when in reality often all that is necessary is one person with very good taste and an eye for detail.

I’m not certain where taste comes from: an innate skill? Perhaps, but not exclusively. In my best estimation, good taste can be learned from paying close attention to the right things, taking a step back and viewing designs from afar often enough, being learned in what kinds of software has been built and was successful in the past, and having a true love of the code. That last part sounds cheesy, but is true enough to reemphasize: if you don’t feel a certain passion for your code and project, it’s a lot easier to let bad taste run rampant, because your care level isn’t as intense as it needs to be.

3. Write code and get your hands dirty.

The best architects realize that code is king. It rules all else. At the end of the day, Visio diagrams, high level vision documents, whiteboard works of art, design documents, emails, functional specifications, and so on, are all a means to an end, not the end itself. The code is your product, and if you don’t understand the code, you don’t understand the state of the project. And if you don’t understand that, you’re not in a position to know what’s working well, what isn’t working, and you can’t possibly have the deep understanding necessary to influence the engineers on the team. You’ve lost control.

The worst architects couldn’t code themselves out of a cardboard box. If you’re not writing actual product code, you’re not an architect: you’re an ivory tower has-been, and probably doing more damage than you are helping matters. Do your team a favor and move into management as quickly as possible.

Writing code also has the benefit of ensuring that you maintain credibility with the team. It’s easy to dictate crazy and grandiose ideas, but if you’re the one who has to implement such a grandiose idea, you’re apt to be more sympathetic with and mindful of the other engineers of the team. You need to keep yourself grounded and writing real product code will help to ensure your technical decision making carefully considers the implementability and down-to-Earth ramifications of your decisions.

Moreover, you need to be a programming expert. People need to respect your abilities, and you want your team to look up to you. You want them to come and ask for your advice because they want it, and enjoy it, and not force them to deal with you simply because of your position on the team. All of the great architects I’ve worked with have inspired me to grow simply because they know so damn much, and because I learn something new every time I interact with them. If they didn’t write code and understand the nitty gritty technical esoterica, this relationship would have been a shallow one.

4. The power of the dyad: know your weaknesses.

Architects need to play a dual role in understanding both business and technical needs and strategy. The degree of business savviness varies greatly among architects, although the best architects I know have a unique ability to understand both sides of the coin. But at the end of the day, they are first and foremost technology wonks, and the business angle is more of a curious hobby. In music, two notes sounding together form dyad, while three or more form a chord. The best architects I know realize their relative weakness on the business end of things and partner up with another senior leader with complementary skills, to fill in the gaps: this forms a harmonic interval. A dyad.

The partnership needn’t entirely be “business” vs. “technical”, although in commercial software that’s more often than not the two opposing forces. For example, my impression of the development of Scheme is that Guy Steele played the role of the architect while Gerald Sussman was the more business-oriented advisor, looking at how Scheme might be used to advance the broader research agenda but not necessarily meddling in the technical design details of the project.

If an architect is 80% technology and 20% business, partnering with somebody who is 20% technology and 80% business can be a killer combination. This allows you to bounce ideas off one another, and to get a certain level of objective feedback from a different perspective. If you’ve got a great technical idea, and bounce it off another techno-nerd, you might spend hours or days debating technical details that ultimately boil down to a matter of taste. But if you take that same idea and bounce it off your business partner, he or she is likely to provide more pertinent feedback: does it make sense from a business perspective, will customers need it, will it open up new product or revenue opportunities, are there more pressing matters to focus the team on, etc. These are things that, being a technology guy (or gal), wouldn’t immediately come to mind. But remember: it’s all about the customer.

5. It’s for the customer, not you.

The best engineers often succeed because they focus on scratching a personal itch. That’s what Linus Torvalds, Bjarne Stroustrup, and countless others did. This is why Donald Knuth created TeX. The idea for a new technology thus begins as a very personal and selfish act. “Build something you’d use yourself, and the customers will come” is a common (cliché) idiom. Although there is certainly truth to this, it’s true only because the very fact that it is bothersome to the founding engineer is likely indicative that it’s bothersome to a broader set of people. It’s an example, where an example is just one element in a set that is used to demonstrate some common attribute among all elements in that set. Those people are your customers.

As a technology matures, it’s important to realize—particularly when building commercial software—that actual human beings will want to use the technology. It’s important to understand and respect their needs. It’s important to, at some point, realize that you’re not, in fact, building a system entirely for your own personal use. Not realizing this point can blind you and make you neglect the need to partner with somebody who understands the business angle of things. It can also lead to a feeling of needing to develop the perfect idealized solution and never ship to customers. Hey, when there are endless technical problems to work on, who would want to ship anyway? By its very definition, shipping software means that you’ve solved all of the major technical problems within a certain scope. What fun is that?

The fun is that you’re able to make an impact on your customers’ lives, hopefully for the better. Your initial technical vision has come to fruition, and you can move on. You get to prove your ideas by having real human beings to use the end product. If you never get to that state, then you’ve done some possibly interesting research—which is hopefully documented and used by somebody someday in the future to actually impact people by delivering a system based on those ideas—but you haven’t architected a product. You’re a researcher, not an architect.

6. Admit when you’re wrong, fall on your sword, and then fix it.

You are going to be wrong sometimes. Trying to do big and bold things necessarily involves some risk. Being an architect requires a careful balance between sticking to your guns—your guiding principles and technical vision—and realizing when things aren’t working out and course correcting before it’s too late. It’s hard to tell when things are beginning to go off course, but when they’ve already gone off course it’s usually obvious. A common telltale sign that things are in trouble is when the team no longer believes in the vision. This may translate into attrition (often of your best engineers first), or just hallway grumblings. Listen carefully. If you’re not involved in the design decisions, writing code, and actually playing a significant role in your team’s daily lives, then you’re apt to miss this. As the architect, you are responsible for responding as quickly as possible to such situations before the shit hits the fan.

Some architects can fall into the trap of using dogma over intellect. Firm principles are of course something I’ve stressed throughout this article. But you need to be honest with yourself and admit when things are not going well. An architect who stands at the helm of a sinking ship, proclaiming that the ship stay its course because the brave new world lies ahead, will only drown (alone) when the ship finally goes underwater. Although this architect can then go around blaming his team for the failure (“if they had only seen the vision and stuck around, we would have succeeded”), the project will be long gone by then. It’s harder, but more noble, to recognize the problems proactively and do your best to fix them.

For example, Tony Hoare describes in the same ACM Turing Award paper mentioned above, how he felt responsible for the failure of the Elliot 503 Mark II project:

“There was no escape: The entire Elliott 503 Mark II software project had to be abandoned, and with it, over thirty man-years of programming effort, equivalent to nearly one man’s active working life, and I was responsible, both as designer and as manager, for wasting it.”

It can be particularly disturbing to realize that a large number of people have been going off in the wrong direction on your watch. Yes, you wasted their time. But you have to learn what went wrong, internalize it, and commit to never making the same mistake twice. You owe it to them to respond promptly. Everybody on the team will have learned and grown from the circumstances, and if you’re lucky the situation is salvageable. Sometimes it won’t be. But in any case you will gain the respect of many around you by making the right decision; particularly if you’re the only person with the broad technical responsibility, understanding, and insight necessary to make such a decision, people will feel relieved when you make it. And if you don’t make it, people will curse you for it.

In conclusion

I’m sure there are many other laundry lists of skills people might come up with that are necessary to be an effective architect, but these are a few of the things I see and respect in the people I look up to. I’ve named some of these people throughout this article. The most common trait is that they have done great things and left their mark on the industry. Being an architect, in the end, is all about helping others to succeed. If you’re a really good architect, you’ll inspire people and rub off on them. You’ll gain a certain level of respect that is unmistakable and priceless. And that, in my opinion, is far more fulfilling than anything you could accomplish on your own working in a vacuum.